1. Field of the Invention
Apparatuses and methods consistent with the present invention relate to event processing technology in a home network, and more particularly to outputting a user interface (UI) event of a 3rd party device in a home network, in which another device can process the UI event of the 3rd party device not belonging to a UI session in the home network.
2. Description of the Related Art
Generally, a home network includes an Internet Protocol (IP)-based private network, and forms a single network having various devices in a home such as all types of personal computers (PCs), intelligent products and radio devices through a common virtual computing environment referred to as middleware, and controls the devices.
Middleware interconnects various digital devices in a peer-to-peer manner and allows these devices to communicate with one another. Home AV Interoperability (HAVI), Universal Plug and Play (UPnP), Java Intelligent Network Infra-structure (Jini), Home Wide Web (HWW), etc., have been proposed as middleware up to now.
In a computing environment constructed through the UPnP middleware, each device receives an address allocated from a server according to a Dynamic Host Configuration Protocol (DHCP), or receives an address selected by an automatic IP designation function, and performs both communication among other devices and search/inquiry on a network through the received address.
A UPnP network, which is a home network having a high possibility of wide use in the near future, defines a UPnP device and a UPnP service, and defines protocols between the UPnP device and the UPnP service. A UPnP network includes both a Controlled Device (CD), a home network device connected to and controlled by an IP-based home network, and a Control Point (CP) which is a device for controlling the controlled device. The control point is a device for performing control for the controlled device, and is an element for requesting and receiving an event. The controlled device is a device for performing a predetermined function at the request of the control point, and is an element for sending the event to the control point having requested the event if the state of the controlled device is altered.
Hereinafter, a related art step-by-step process among UPnP network devices will be described. The process includes a discovery-advertisement process, a description process, a control process and an eventing process.
The discovery-advertisement process includes an advertisement process in which a new controlled device is connected to a home network and advertises the existence of the new controlled device to other devices on the home network, and a discovery process in which a new control point is connected to the home network and searches for controlled devices operating on the home network.
The description process is a process in which the control point parses a service description Extensible Markup Language (XML) file or a device description XML file through the IP address of the controlled device, which is obtained through the discovery-advertisement process, in order to control the controlled device, and recognizes the function of the newly added device in more detail.
The control process is a process in which, when the control point is to provide a specific service through a controlled device, the control point transmits an action request for requiring a predetermined service to the corresponding controlled device by means of a SOAP according to a UPnP device architecture, and receives a result or a variable value for the transmitted action request.
The eventing process is a process for checking the information change state of the controlled device having received the predetermined service according to a control command transmitted from the control point. This process will be described with reference to FIG. 1.
Referring to FIG. 1, it can be understood that the control point and the controlled device perform the eventing process in a one-to-one fashion. First, if the control point transmits a subscription request to the service of the controlled device in order to check the information change state of the controlled device, the service of the controlled device transmits an XML type event message formatted through a Generic Event Notification Architecture (GENA) to the control point in order to report the changed information. The control point receives the event message from the controlled device, and processes the event message as a description update item for the controlled device. If the control point is to continuously receive an event even when a subscription period has expired, the control point transmits a renewal request message to the service of the controlled device and requests the increase of the subscription period. Then, the service clearly defines a new subscription period and permits the subscription. However, if the control point is not to receive the event any more, the control point may cancel the subscription by transmitting an unsubscribe message to the service of the controlled device.
FIG. 2 is a diagram illustrating a related art eventing process proposed by a UPnP Remote User Interface (RUI). First, a control point 10 acquires protocol information from an RUI server 20 and an RUI client 30, which correspond to controlled devices (S11). Further, the control point 10 acquires all available UI information that can be provided from the RUI server 20 through the RUI client 30 (S12), and selects a proper UI to be outputted through the RUI client 30 (S13). Then, the control point 10 connects to the RUI client 30 and requests the output of the selected UI (S14), and the RUI client 30 having received the request forms an out-of-band protocol with the RUI server 20 and outputs the UI information (S 15).
Generally, if the state of a controlled device changes, the controlled device transmits an event message to a control point in order to report the state change. In the UPnP remote UI as described above, if the UI state of the RUI server 20 changes, the change of the UI state can be reported to the RUI client 30 only through a remote protocol between the RUI server 20 and the RUI client 30, in addition to the event defined in the UPnP protocol. That is, the report is possible only when a remote protocol session between the RUI server 20 and the RUI client 30 is in progress.
However, if a 3rd party device exists and is to report its own state, it is difficult to apply an existing remote UI method. Actually, a UPnP remote UI specification provides a DisplayMessage Action in order to overcome such a disadvantage, but the action is possible only when a device performing a CP function must be included in the RUI server 20. That is, the RUI server 20 performs the function of a controlled device of a UPnP, and the RUI server 20 must have the function of a UPnP CP in order to simply call the DisplayMessage Action. In such a case, it is inefficient in a device having insufficient resources, and unnecessary network traffic may occur due to the addition of the CP function.